Plasma Cash Simple Spec

---.icon

Overview

Plasma Cash is a Plasma construction based around the use of unique identifiers for each token on the Plasma chain. Similar to cash in your pocket, tokens on the network are given unique serial numbers. Out of this change comes a number of benefits.

Plasma Cash では、Plasma チェーンの各トークンに対してユニークな識別子がつく。お金と同じようにシリアルナンバーが与えられる。この変更による恩恵がいくつかある。

水平分割されたクライアントサイド検証

クライアントは自身のトークンだけを監視していればいい

すなわち、個々のユーザーに負担をかけることなく、トランザクションのスループットが向上する

confirmation 不要

その代わり、トランザクションが親チェーンに取り込まれた時点でコインは使用済みになる

全てのトークンをサポート

non-fungible なトークン含め、異なるトークンも簡単に追加できる

mass exit 問題の軽減

盗みたいトークンごとに exit を行う必要があるので、mass exit 問題の心配がいくらか軽減される

チェーンが停止してもトークンは安全だが、サービスの中断は発生してしまう

A downside is:

欠点は以下。

大きなトークン単位

各トークンにはシリアルナンバーが割り当てられるので、任意に小さなトークンを生み出すことはできない

トークンを償還する際の gas コストがトークンの価値を超えてしまうため

Transaction roots

For every block in the Plasma Cash chain, a merkle root must be published to the root chain. This root can either be a merklized list, or a merkle patricia tree. In the merklized list, each index of the leaf nodes corresponds to the token ID. The values of the leaf nodes are Plasma transactions.

Plasma Cash チェーンの全てのブロックの Merkle root は親チェーンで公開される。この root は Merklized list でも Merkle Patricia tree でもよい。Merklized list の場合、leaf node の各インデックスはトークン ID に対応し、leaf node の値は Plasma トランザクションに対応する。

Transactions take the form:

トランザクションの形式は以下のようになる。

[[prev_hash, prev_block, (target_block?), token_id, new_owner], signature]

Minting

Spending

The spender must provide to the recipient a full history of the particular token they wish to spend. The history consists of:

トークンの送り手は、送りたいトークンに全ての履歴を受け手に提供しなければならない。履歴の内容は以下。

・Every time a transaction spending the token was included in the Plasma chain, a Merkle proof of this must be supplied.

・For every Plasma chain block during which that particular token was not spend, a Merkle proof-of-nonexistence must be provided; that is, a Merkle branch proving that at the index in the Merkle tree corresponding to the coin there is empty data, and not a valid transaction.

Merkle proof

トークンを使用するトランザクションが Plasma チェーンに含まれる度に提供される

Merkle proof-of-nonexistence

トークンが使用されなかった場合でも、全ての Plasma チェーンのブロックについて、これが提供される

トークンに対応するインデックスに何もデータがなく、正当なトランザクションもないこと証明する Merkle branch

The recipient then checks the token's history for any invalidity or withheld blocks. Assuming no problems, the recipient can now spend the token.

受け手はトークンの履歴をチェックし、不正がないことを確認する。問題なければ受け手は受け取ったトークンを使うことができるようになる。

---.icon

Exits

Exits allow users to retrieve their tokens on the main chain. Invalid exits can be challenged by any user with the token's data. Each exit also contains a bond which covers the gas cost of a challenge plus a bounty for proving invalidity.

ユーザーは exit によって親チェーン上でトークンを引き出す。不正な exit に対する challenge は誰でもできる。challenge の gas コストと challenge 成功時の報酬をカバーするため、各 exit には担保が含まれる。

There are three types of exit challenges, they are as follows:

challenge は以下の 3 種類。

https://gyazo.com/e301b05a6d9343f3d54d4c1dfa7c0330

1. exiter が 3 の exit を申請する

2. challenger が 4 とともに challenge することで exit はキャンセルされる

https://gyazo.com/57cc1e2f621069263a4b39302bedbefa

1. exiter が 4 と 2 とともに 4 の exit を申請する

2. challenger が 3 とともに challenge することで exit はキャンセルされる

3 は 4 よりも前のブロックに含まれており、4 の親を使っているため

https://gyazo.com/13977a3daa36db68e191da9cc92fc8f0

1. exiter が 5 と 4 とともに 5 の exit を申請する

2. challenger が 2 と 1（最後の正当なトランザクション）とともに challenge する

3. exiter が 2 の正当な子を提出できなければ exit はキャンセルされる

重要なのは、不正なブロックが未公開であっても challenge が成立するということ。exiter が 2 の子を偽造していたとしても、challenge は止めれない。

---.icon

Further Research

Partial Spends

There are a number of ways to achieve partial spends. One simple solution is allow token IDs to support decimals. A token can then be broken into smaller pieces and later exited on the root chain. A drawback of this apporach is if a token is split too small, then it could once again not be worth it to withdraw.

partial spends を実現する方法はいくつかある。シンプルな方法は、トークン ID が小数をサポートすること。そうすれば、小さく分割したトークンを exit することができる。このアプローチの欠点は、トークンを小さく分割しすぎると引き出す価値がなくなってしまうこと。

Ideally, one could split tokens, transact on the Plasma chain, and then combine a bunch of small tokens into one large one and exit. This seems quite possible but a spec for doing so is still in the works.

理想的には、トークンを分割でき、Plasma チェーン上で取引した後に 1 つに結合して exit できるとよい。これは可能だと思うが、まだ仕様が固まってはいない。

Another approach worth noting is probabilistic payments. This basically means instead of paying you $0.50, I pay you $1.00 50% of the time. This can be useful for micropayments.

注目に値する別のアプローチは、確率的ペイメントである。これは例えば、「$0.5 支払う代わりに、$1 を 50% の確率で支払う」ということ。これはマイクロペイメントに対して有効。

Compact Spend History

Having to verify a token's history could be quite expensive if implemented poorly. It would be great if proofs of non-membership in the transaction list were easy to achieve with minimal bandwidth. Ideally one can use a zkSTARK of the history for super fast compact token history checking.

実装がしょぼかった場合、トークンの履歴の検証が非常に重たくなってしまう。proof-of-nonexistence がより簡単に最小の帯域幅で実現できたら素晴らしい。理想的には、トークンの履歴の検証を高速かつコンパクトに行うために zk-STARK が使えるとよい。

Efficient Exit Challenges While Allowing Invalid Transactions

In the simplest version of the spec, we assume that after an invalid transaction all subsiquent transactions are invalid. Therefore, if you prove there was a single invalid state transition then the only person who can exit is the owner of the token right before the invalid transaction was included. This allows us to make the exit logic super simple.

最もシンプルな仕様では、不正なトランザクションの後に続く全てのトランザクションは不正とみなされる。よって、一度でも不正な状態遷移があったことが証明されれば、トークンを exit できる唯一の人間は不正なトランザクションが含まれる前のトークン保有者だけとなる。このおかげで exit のロジックが非常にシンプルになる。

In theory there is no problem with invalid state transitions in a token's history. Because users will validate each token's history, the user can just ignore the invalid spends. However, exit logic becomes more complex. Exits must then prove that not only is the spend valid, but that there are no invalid spends in the coin's history. There may be some nice acumulator which could help do this efficiently, but that's open research.

理論的には、トークンの履歴に不正な状態遷移があっても問題はない。ユーザーは各トークンの履歴を検証できるので、ユーザーは不正な使用を無視するだけでいい。しかし、exit のロジックはより難しくなる。トークン自体が正当であることだけでなく、トークンの履歴に不正な使用がないことも証明しなければならなくなってしまう。これを効率的に行う助けとなる優れたアキュムレータがあれば解決できるかもしれないが、今のところは未解決。

Block Withholding

It would be nice if a Plasma chain can recover from unavailable blocks being added to the root chain. The problem with unavailability is if a block ever becomes available at a later date, it can invalidate honest user's transactions. This is quite scary, and it turns out data availability is one of the hardest problems in blockchain design.

unavailable なブロックが親チェーンに追加された状態からもリカバリできるとよい。unavailable なブロックの問題は、後にそれが available になったときに誠実なユーザーのトランザクションを無効にできてしまうということである。これは非常に恐ろしい。データの availability はブロックチェーンの設計において最も困難な問題の 1 つでもある。

To get a sense for the problem, consider the following diagram:

問題を理解するために、以下の図を使って考える。

https://gyazo.com/614f4e771791badc610e569f6281a643

Time 1：ブロック 3 が withhold されているので、誠実なユーザーから見たトランザクション 4 は正当

Time 2：ブロック 3 が available になった瞬間、トランザクション 4 は double spend となってしまう

unavailable なブロックが存在した場合、攻撃者はいつでもそのブロックを available にすることでユーザーのトークンを無効化できてしまうので、ユーザーは後続のトークン使用が正当かどうかを知る術がない。ひどい！ひどい！ひどい！

A recovery method for block withholding would be nice. Blocks could be unavailable but after some mechanism ran its course, a recovery could be made without having to exit tokens back onto the main chain. It is worth noting that tokens are safe even on a Plasma chain with unavailable data. However, a mechanism like this would allow tokens to both be safe and live (transferable).

block withholding からのリカバリ方法があるとよい。ブロックが unavailable であっても、いくつかのメカニズムがきちんと機能すれば、親チェーンへトークンを exit する必要なくリカバリは可能。unavailable なデータを含んだ Plasma チェーンにおいてもトークンは安全であるということは注目に値する。このようなメカニズムはトークンの安全と生存を実現する。